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Abstract — In this paper we apply a model-driven engineer- 
ing approach to designing domain-specific solutions for robot 
control system development. We present a case study of the 
complete process, including identification of the domain meta- 
model, graphical notation definition and source code generation 
for subsumption architecture - a well-known example of robot 
control architecture. Our goal is to show that both the definition 
of the robot-control architecture and its supporting tools fits 
well into the typical workflow of model-driven engineering 
development. 

I. INTRODUCTION 

There is a long history of development of robot control 
architectures, however, there exists no precise definition of 
this term. Moreover, their designing is still much more of an 
art than a science [1]. We believe that while one may argue 
about the ideas behind a particular robot control architecture, 
a systematic engineering approach can be applied to the 
process of designing an architecture itself. 

A. Robot control architectures 

The work on robot control architectures began in the late 
1960s with the sense-plan-act (SPA), a dominant paradigm at 
that time [1], [2]. This approach, originated from the artificial 
intelligence community, decomposes a control system into 
three functional layers dealing with sensing state of an 
environment, planning an optimal action based on symbolic 
representation of the current state and finally executing 
selected action. Even if robot succeeds extracting a mean- 
ingful representation of a world model from raw sensor 
data, it usually takes a long time to plan for correct action. 
As a result, the executed action often corresponds to the 
already outdated sensor readings. Because of this, the SPA 
architecture fails to provide the robot with a robust operation 
in the real world, noisy and unpredictable environments. 

In the mid-1980s limitations of the SPA architecture were 
recognized and the robotics community turned towards more 
reactive, behavioural approaches to robot control. Probably 
the most wide-known example is the subsumption architec- 
ture of Brooks [2]. A subsumption architecture is built from 
a set of small processors (referred to as modules) which sends 
messages to each other. These modules make up layers of 
control corresponding to different levels of competence, e.g., 
dealing with obstacle avoidance, wandering, exploration, 
map building and navigation. The subsumption architecture 
proved to be successful in operating within unpredictable, 



noisy environments. However, it was difficult to assign 
a long-term, complex task to a robot executing just a set 
of relatively low-level behaviours. 

Limitations of behaviour-based controllers led to the de- 
velopment of layered robot architectures [3]. These archi- 
tectures combine real-time control, action sequencing and 
planning as bottom, middle and top layers, respectively. The 
challenge of developing a layered control system consists 
both of representing and solving problems at the individual 
layers, as well as integrating individual levels of control. 
Because of different requirements and constraints, a typical 
approach is to use dedicated domain-specific languages at 
individual layers [1]. While portable middleware and APIs 
allow for software reuse between different architectures [4], 
in most cases it is still difficult to separate architectural 
concepts from their implementation. 

B. Model-driven engineering 

Model-driven engineering (MDE) technologies com- 
bine [5]: 

• Domain-specific modeling languages (DSMLs) whose 
type systems formalize the application structure, be- 
haviour, and requirements within particular domains. 

• Transformation engines and generators that analyze 
certain aspects of models and then synthesize various 
types of artifacts, such as source code. 

DSMLs are typically specified with meta-models, which 
have significant advantages over other techniques, such as 
BNF grammars or UML profiles [6]. The choice of a meta- 
modeling technology depends mainly on the availability 
of tools supporting the development of a complete solu- 
tion. MetaEdit+ was among the first commercially available 
domain-specific development environments [7]. Increasing 
market interest has been recognized by Microsoft, thus the 
release of Microsoft Domain-Specific Language Tools in 
2005 [8]. The Eclipse Modeling Framework [9], [10] is 
the leading open-source competitor in the field. It provides 
advanced support for both graphical and textual notation 
of modeling languages, as well as validation of model 
constraints, model-to-model and model-to-text transforma- 
tions. Individual tools of the framework follow the Object 
Management Group (OMG) standards [11], [12], [13]. 

This paper is structured as follows. Section II presents an 
overview of the Eclipse Modeling Framework - one of the 



most popular model-driven engineering technologies avail- 
able. Section III presents application of the meta-modeling 
approach to capturing concepts of an exemplary robot control 
architecture. A complete environment for development of 
a robot control system, including generation of application 
code skeleton, is presented. Section IV compares this work 
with existing approaches. Section V presents conclusions and 
remarks. 

II. THE ECLIPSE MODELING FRAMEWORK (EMF) 
PROJECT OVERVIEW 

The EMF project is a modeling framework and code 
generation facility for building tools and other applications 
based on a structured data model [9]. The accompanying 
projects enable the development of a complete modeling 
solution, including textual and graphical editors, validation of 
model constraints, model-to-model and model-to-text trans- 
formations [10]. 

Ecore, the underlying data model of EMF, is aligned on the 
Meta-Object Facility OMG standard [11]. The Ecore model 
includes elements known from object-oriented programming, 
such as classes, attributes and references (i.e., composition, 
inheritance and associations) [9]. The cardinality of attributes 
and references is expressed with lower and upper bounds. 
Complex model restrictions are specified by the use of Object 
Constraint Language (OCL) expressions [12], [14]. Con- 
straint statements are defined in the contexts of an individual 
classes and specify invariants related to their attributes and 
relationships. 

The EMF models are typically presented with graphical 
notation, which is based on UML class diagram nota- 
tion [15]. However, in opposition to the models created in 
UML, the models created with meta-modeling solutions are 
formal and precise [7]. 

The EMF is accompanied by several satellite projects, 
which support different steps of a typical model-driven en- 
gineering workflow. These include tools for the development 
of graphical and textual notations, languages for model-to- 
model and model-to-text transformations, model validation 
and constraint checking [10]. It is important to note, that 
these tools can be used interchangeably or in addition to 
those which have been applied in the following use case. 

III. DOMAIN-SPECIFIC SOLUTION 

The subsumption architecture is one of the most well- 
known robot control architectures. While its limitations 
have been already identified [3], it is still introduced at 
many preliminary robotics courses. Subsumption systems 
were originally intended for hardware implementation as a 
network of cooperating processors. Later, the same set of 
concepts was implemented as the Behaviour language [16] 
- an extension to Common Lisp that enabled both the 
execution of the program on the host machine and the 
compilation into microcontroller assembly code, which was 
executed on-board the robot. 

In the original paper by Brooks, the architectural concepts 
were introduced informally and without detailed definition 



of their semantics [16]. This approach sufficed to attract 
interest in the new approach to robot programming, how- 
ever, it should not be regarded as the approved way to 
define robot control architectures. The following section 
describes domain-specific solution for the development of 
a subsumption-based robot control system. Individual sub- 
sections follow format of presentation found in [7]. Our 
goal is to show that both the definition of the robot-control 
architecture and its supporting tools fits well into the typical 
workflow of model-driven engineering development. 

A. Introduction and objectives 

The subsumption architecture differs fundamentally from 
the typical sense-plan-act approach, which was initially the 
predominant architecture. One of the main differences is 
that it breaks a typical sequential data flow that simply 
links sensors to actuators. Instead, a subsumption-based robot 
control system consists of a set of asynchronous processors 
(modules) interconnected with wires, which enable both data 
and control flow. 

Internal operation of a processor is described by an aug- 
mented finite state machine (AFSM) [2]. The processor is ca- 
pable of: (1) sending a new data message with an output wire, 
(2) modifying its internal memory variables, (3) conditional 
dispatching based on predicates on it's internal variables and 
values of the input buffers, as well as (4) event dispatching 
based on monitoring input wires for arrival of a new message 
with an optional timeout. The latest data from an input wire 
are held in a module's input buffer. However, the exact 
semantics of the AFSMs is not specified formally. 

The core architectural concepts are related not to the 
individual processors, but to their operation as a network. The 
processor's operation can be easily described using any of the 
existing general-purpose programming languages extended 
with library calls for inter-module communication. In fact, 
the Behaviour language did not specify the AFSMs directly, 
but rather with sets of real-time rules [16]. However, in 
this paper we focus only on the architecture and not on the 
patterns for building the AFSMs. 

1 ) Target Platform and Environment: While it is possible 
to implement a robot control system directly in hardware 
(e.g., using gate arrays or analog circuits), most of the robots 
are equipped with on-board computers. On-board processor 
systems range from a single microcontroller (e.g., Lego 
Mindstorms NXT) to a cluster of PC-s (e.g., autonomous 
vehicles in the DARPA Grand Challenge competition [17]). 

The ultimate goal of a robot control system architecture is 
to provide developers with a skeleton, which can be just filled 
with data types definitions and implementation of control 
algorithms. Because of the multitude of existing operating 
systems and middleware available, there is no a single plat- 
form for the deployment of a control system. Instead, code 
portability is the most valuable feature and one of the main 
concerns. To increase the portability of the control software, 
the generated application software should not be specific to 
any particular operating system, but should be layered on 
top of a well-defined programming interface. In addition, 



a well-chosen interface (target environment) can significantly 
decrease complexity of model-to-code transformations. An 
example of such an interface is provided by the POSIX 
standard, which defines both the API and the set of tools, 
required to build an executable binary [18]. However, the 
environment defined by the POSIX is of a relatively low level 
and at the same time requires a significant support on the side 
of the underlying operating system (e.g., dynamically created 
threads and synchronization primitives). 

In our approach we have decided to use the Ada program- 
ming language as a target of code generation [19]. Ada is 
a general-purpose programming language, originally targeted 
at embedded and real-time systems; it has been already 
successfully applied to robot control [20], [21]. Our choice 
is motivated mainly by the wide set of features supported 
at the language level, including advanced multi-tasking and 
distributed systems. 

In particular, two extremes of robot platforms are exten- 
sively supported by Ada, namely, deeply embedded systems 
with limited resources and large, heterogeneous distributed 
environment. The former case is addressed by the Ravenscar 
profile, which is a subset of the language restricted to met 
the requirements for determinism and schedulability analysis, 
as well as being suitable for mapping to small runtime 
systems of resource-limited platforms [22]. The latter case is 
addressed by the Distributed Systems Annex, which enables 
the execution of a multi-tasking Ada program on a set of 
distributed processing nodes [23]. Both cases require anno- 
tations of Ada code with standard-defined pragmas (compiler 
directives). The pragmas related to the Ravenscar profile are 
compatible with those related to the Distributed Systems 
Annex. Thus the same source code can be used to build both 
executables for distributed system, as well as an executable 
for a resource-limited embedded board. This flexibility and 
portability was our main motivation for using Ada, however, 
other targets for the code generation are possible as well. 

2) Objectives: The objective of this modeling solution is 
to ease the development of the subsumption based robot 
control systems. This goal is achieved by allowing the 
designer to specify the structure of the control system in 
an intuitive graphical notation and then to automatically 
generate a code skeleton of the final application. The code 
skeleton has to be filled with routines (portions of code) 
with implementation of the data processing algorithms and 
interface with the robot's sensors and actuators. 

A model-driven approach allows to generate multiple 
artifacts from a single source model. Thus it is possible 
to provide the designer also with additional model-to-code 
transformations, e.g., generation of a documentation tem- 
plates or unit tests. 

B. Development process 

Development of a domain-specific solution starts with 
identification of the modeling concepts. In the case of robot 
control architectures the main references are publications 
with details of a given architecture. Evaluation reports and 
source code of existing applications can be also valuable 



sources of information, but these are not always publicly 
available. Moreover, authors typically point out the core 
architectural concepts and their attributes, but concept re- 
lationships and their constraints are often introduced only 
informally. Thus, the main challenge usually is to find 
relationships of the architectural concepts, their type and 
cardinality. 

The naming used within a domain-specific solution usually 
follows the naming of the architecture's authors. However, 
some of unnamed relationships (and opposite relationships 
in particular) are often required for navigation in the model 
transformations. In these cases, the developer of a domain- 
specific solution can use arbitrary names, since they will not 
be directly visible to end users. 

For the robot control architectures, there are typically no 
more than several core concepts and relationships to model. 
Authors tend to intentionally avoid architectural complexity, 
which would result in structures that are difficult to analyze 
and understand by end users. In the case of subsumption ar- 
chitecture the main effort in creating a domain-specific solu- 
tion was to develop a graphical notation editor corresponding 
to the original notation and model-to-code transformation, 
rather than identifying the meta-model of the domain. 

C. Modeling language 

The domain-modeling language for subsumption-based 
robot control system collects concepts and their relationships 
from the original publications [2], [16]. The benefit of using 
meta-modeling for language specification is a much clearer 
presentation of its structure compared to informal description 
in natural language only. 

1) Modeling concepts: The root element of the 
subsumption-based robot control system modeling language 
definition is System itself, as it contains instances of all 
other elements of the language (Fig. 1). The mandatory 
name attribute is used to identify an instance, while the 
optional description is included for documentation purpose 
only. These general attributes will be common also to other 
concepts of the domain; they are used to generate names 
and comments in code skeletons and documentation. 

The System is composed of Modules, each corresponding 
to a single activity within a control system. The mandatory 
layer attribute specifies to which level of competence a par- 
ticular module belongs to [2]. The purpose of this attribute 
is to facilitate testing of the control system by separately 
enabling or disabling individual layers in runtime. Each 
Module contains both InputLines and OutputLines, which can 
receive and send data from/to other modules, respectively. 
DataType attribute specifies the type of messages transmitted 
with the individual lines. It is required that the data type of 
an input line is convertible to a data type of a corresponding 
output line. The strong typing feature of the Ada type system 
enables checking this requirement at compile time, thus 
enforces matching of modules' interfaces. 

A connection wire between InputLine and OutputLine is 
modeled with the source and sink relationships. The upper 
bound on the cardinality of the source relationship equals to 
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one - each InputLine may be wired to at most one OutputLine. 
On the other hand, there is no upper bound on the cardinality 
of the sink relationship - each OutputLine can be wired to 
several InputLines. 

The key feature of the subsumption architecture is the 
ability to suppress data incoming into one module's input 
by data outgoing from another module's output and sim- 
ilarly to inhibit one module's output data with another's. 
These features are modeled with Suppressor and Inhibitor 
concepts, which intercept transmission on the wires incoming 
to InputLine and outgoing from OutputLine, respectively. The 
interception is done by messages outgoing with OutputLine 
specified with the controlledBy relationship. This relationship 
is common for both Suppressor and Inihibitor, thus it has been 
assigned to a common abstract Modifier concept. The time 
attributes specify for how long after the arrival of a message 
on the control line the data transmission remains intercepted. 
They have not been assigned to the Modifier concept, since 
they are distinct properties of the Suppressor and Inihibitor. 

2) Modeling rules: In addition to concepts, their attributes 
and relationships, it is often necessary to include more de- 
tailed restrictions on the domain meta-model. For the ECore 
they can be described using the Object Constraint Language 
(OCL) expressions [12], [14]. OCL is a declarative language 
that enables one to precisely specify constraints on the 
model, e.g., values of attributes and scope of relationships. 

In the case of the subsumption control architecture meta- 
model, OCL expressions are used to limit the scope of the 
interception relationships (i.e., suppressors and inhibitors) 
and the allowed range of the numerical attributes (listing 1). 
OCL expressions typically consist of the context keyword 
followed by a class name and inv: keyword followed by 
class invariant definitions. Dot notation, similarly as used in 
object-oriented programming, enables the navigation within 
a model to specify a constraint on a related concept. The self 
keyword is used to address the context's attributes explicitly. 

3) Modeling notation: Notation is one of the most impor- 
tant aspects of the domain-specific modeling solution from 
the end user's point view. It is worth to note, that it is possible 
to have multiple notations for a single modeling language. 



context Module 

— it is only possible to intercept data transmission 

— on the same layer and below 

inv: outputs . controls . oclAsType (InputLine) . 

Module. layer <= self. layer 
inv: outputs . controls . oclAsType (OutputLine ) . 

Module. layer <= self. layer 

— transmission 's interception time is always positive 
context Inhibitor 

inv: time > 

context Suppressor 
inv: time > 

Listing 1. OCL invariants imposed on the domain's meta-model 



Different notations may be useful for users depending on 
their experience level or their roles in the development 
process (e.g., project managers and developers). In particular, 
in the inter-disciplinary domains such as robotics, it may be 
beneficial to discuss the high-level models using an intuitive, 
graphical notation (possibly with some details hidden from 
the view). 

Notation does not influence in any way the expres- 
sive power of a domain-modeling language. However, non- 
intuitive diagrams (in the case of graphical notation) or 
obscured syntax (in the case of textual notation) can easily 
discourage potential users from adopting the solution. The 
EMF project supports development of both graphical [10] 
and textual [24] notations for modeling languages. A proto- 
type graphical notation for a given domain meta-model can 
be built with easy to use wizards and then customized, e.g, 
with domain-specific symbols. Prototype textual notation can 
be also generated automatically [25] and then customized. 

In general, it is much easier to develop both graphical 
and textual notation from scratch, than adapt automati- 
cally generated prototypes to match pre-existing conventions. 
However, in this paper we follow the latter approach to show 
that model-based engineering can be also applied to legacy 
domains. The graphical notation we adapt to is taken directly 
from the Brooks original paper [2]. While this notation 



is well-known among the robotics community, to our best 
knowledge, there exists no graphical environment, which 
would allow for development of the subsumption-based robot 
control systems. 

The graphical modeling notation of a subsumption-based 
control system consists of a single diagram (Fig. 3). The root 
element of EMF diagram is the canvas, which correspond to 
the root element of the domain meta-model. A single canvas 
contains a number of figure definitions, which are then 
referenced by logical elements of the diagram, i.e., nodes, 
connections, compartments and labels. Figures are typically 
defined with a set of predefined shapes (e.g., rectangles, 
ellipses, polylines) and their attributes (e.g., width, color, 
size). However, it is also possible to create custom figures 
using Java and the underlying graphics toolkit. Logical 
elements of the diagram are then mapped to the domain 
meta-model. Nodes are typically mapped to domain con- 
cepts, connections to domain concepts' relationships and 
labels to concepts' attributes. Compartments are designed 
as containers for other diagram elements and typically are 
mapped to the containment relationships of the domain meta- 
model. 

In the subsumption-based control system notation the Sys- 
tem (root element) is represented with a white background 
canvas. Individual Modules are represented by rectangles 
with centered label containing the module's name attribute 
(Fig. 2). Both InputLine and OutputLine concepts are rep- 
resented by compartments of rectangular shape with line 
connecting their left and right sides (in the case of InputLine 
there is also an arrow head at the right end of the line). 
InputLines can be placed only on the left border of the 
module's figure, while OutputLines only on its right border. 
The name attribute of the OutputLine concept is represented 
by floating label, similar to the original Brooks notation. 
Both the Suppressor and Inhibitor concepts are represented 
by circles, respectively with the S and I characters and 
labels corresponding to their time attribute. The sink/source 
relationships are represented by lines connecting the corre- 
sponding InputLine and OutputLine diagram elements. The 
controls/controlledBy relationship is represented by arrows 
from the OutputLine to one of the Suppressor and Inhibitor 
diagram elements. Relationship connections can be anchored 
only at specified locations of the diagram elements (top in 
the case of Suppressor and Inhibitor figures, while left and 
right in the case of InputLine and OutputLine, respectively). 
A palette with tools mapped to individual domain concepts 
and relationships is also included and can be easily cus- 
tomized with icons corresponding to the domain elements. 

The customized graphical notation solution built with 
the EMF project consists also of many generic features, 
which otherwise had to be implemented manually. These 
include outline view of the diagram and structural view of 
the model, diagram grid, snapping connections to anchor 
points, zooming, automatic layout and alignment of diagram 
elements, printing, exporting to bitmap and vector image 
formats (Fig. 3). Diagrams and models can be stored using 
the XMI (XML Metadata Interchange) file format, thus an 
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interoperation with tools from outside of the EMF project is 
also possible. 

D. Modeling subsumption control system 

The presented domain-specific modeling solution has been 
tested by developing an exemplary control system for an 
autonomous mobile robot. Both the application scenario 
as well as design of modules and their interconnections 
has been reused from the original Brooks paper [2]. Our 
main motivation was to keep the reader's focus on the 
approach itself, rather than on the details of the implemented 
application scenario, robot design or control algorithms. 

One of the main drawbacks of the subsumption archi- 
tecture is that a controller is not task-oriented (and non- 
taskable). Rather, the behaviour of the robot emerges from 
interactions of controller's modules. Thus, the goal of the 
mobile robot is simply to autonomously operate in an 
unstructured environment, including obstacle avoidance and 
possibly exploration of interesting locations. Similar to the 
original paper, experiments have been performed both on 
simulated and real robots. 

It should be stressed that the goal of this paper is not the 
evaluation of the subsumption architecture or the particular 
instance of the controller. The focus of the paper is rather 
on evaluation of model-driven engineering approach to de- 
signing robot control architectures. 

1 ) Example model: The exemplary model consists of two 
layers of the original control system presented by Brooks, 
i.e., avoiding contact with objects and wandering aimlessly 
without hitting obstacles [2]. Exploration (the third layer) 
requires more advanced sensors (in the original paper a tilt 
head with stereo camera has been used) and data processing 
algorithms (image feature extraction, path planning). 

Individual modules are responsible for: filtering and pro- 
cessing sensor range data into robot centered map of obsta- 
cles (sonar), detecting collisions (collide), computing repul- 
sive forces from obstacles (feelforce) and monitoring their 
sum (runaway), generating a new heading for the robot 
(wander) and combining it with the data about obstacles 
(avoid) (Fig. 3). Finally, turn and forward modules interact 
with the motors. A single suppressor intercepts heading 
generated by the runaway module with that generated by 
the avoid. 

2) Use scenario: Modeling an instance of subsumption- 
based control system begins with the definition of individual 
modules together with their output and input lines. After- 
wards, the output and input lines are connected by wires. 
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Suppressor and inhibitors are created, assigned activation 
time and their control lines as required. Names and descrip- 
tions in the model are also required, as they are used to 
generate the source code. Individual OCL rules are enforced 
during model development. 

When the model definition is completed, then it is possible 
to automatically generate skeleton of the robot control system 
application. Individual modules are translated into separate 
Ada packages, thus the structure of the source code follows 
the structure of the model and the code corresponding to 
each module can be compiled separately. A user is required 
to provide (1) specification of the data types assigned to input 
and output lines and (2) bodies of procedures that implement 
AFSMs executed within individual modules. Implementation 
typically begins from modules responsible for getting sensor 
data and can be incrementally tested, even if another modules 
are not yet completed. 

E. Generator for Ada 

Generator for the robot control system has been imple- 
mented in Acceleo, an Eclipse implementation of the OMG 
Model to Text Transformation language [13]. Transformation 
consists of navigating an instance of the control system 
model, starting from the root System and applying a template 
of Ada code to the concepts of the domain meta-model. Ada 
code templates have been extracted from a hand-written im- 
plementation of a simple subsumption-based control system. 
The generator produces both the source code and a project 
configuration file for the Ada IDE editor. 

1) Generator structure: The generator structure corre- 
sponds to the structure of the initial, hand-written Ada 
source code. Individual templates generate packages with the 



implementation of the module's interface (procedures to send 
data with input lines), input buffers (where new data values 
are stored until received by AFSM), and main task (which 
executes AFSM). A separate template generates specifica- 
tions of procedures, which implements internal operations 
(AFSMs) of the modules. 

2) Generator in action: The complete generator consists 
of 9 files with a total of about 700 lines of Acceleo's 
template code. For an exemplary controller with 8 modules, 
about 1800 source lines of Ada code (excluding white space 
and comments) were generated. This code is responsible 
for the initialization of tasking constructs, input line buffers 
and connection wires. The internal operation of modules 
(AFSMs) has been manually implemented with about 200 
lines of code, which is only about 10% of the complete 
application. It should be noted that all aspects of tasking and 
concurrency (which are relatively more difficult to develop 
and debug) are handled by the automatically generated code. 
Thus, a developer can focus on data processing algorithms 
only and not on implementation of the architectural concepts. 

F. Framework support 

The generated source code purposely does not rely on 
any software framework other than standard features pro- 
vided by the Ravenscar profile subset of Ada, i.e., tasks 
and protected types [22]. This allows to build the control 
application for resource limited and embedded platforms, 
which lack features like terminal console or filesystem. 
Generated code automatically benefits from using multi-core 
processors, since every module is executed within a separate 
Ada task. It is also possible to compile the code into a 
distributed application [23]. In this case individual modules 




Fig. 4. Paths of the subsumption controlled robot in simulated environment 
with only the first one (light green) and both layers enabled (dark green) 

can be transparently executed on separate network nodes 
(e.g., computationally expensive data processing can be off- 
loaded). 

It is possible to provide alternative generators for platforms 
with more features available (e.g., data logging, interactive 
debug console, runtime configuration files). In such case a 
separate software framework should be provided to avoid 
unnecessary complexity of a generator's templates. 

G. Main results 

The exemplary control system has been tested with both 
simulated and real-world robots. Because of limitations of 
the Lego Mindstorms NXT platform only three range finders 
were used (in the original Brooks research a ring of twelve 
sonar sensors has been used). 

For the simulation the Player/Stage software suite has been 
used [26] together with client library bindings for Ada. In the 
simulated environment two versions of controller have been 
tested, with the first competence layer disabled and enabled 
(Fig. 4). Performance of the controller strongly depends on 
the parameters of individual modules (i.e., collision distance, 
repulsive force settings). However, the layer with wander 
behaviour clearly cause the robot to operate more robustly 
and explore a larger area. 

For real-world experiments the Lego Mindstorms NXT 
platform has been used, which provides only 64kB of RAM 
and 256kB of flash memory. An executable image, which 
consists of Ada Ravenscar runtime, NXT device drivers, in- 
ternal code of the subsumption modules and the inter-module 
data buffers, is only about 50kB in size. The Ravenscar 
profile does not put any restrictions on the sequential (i.e., 
non-tasking) features of Ada and the architectural footprint 
of the generated application is minimal. 



IV. RELATED WORK 

The subsumption architecture has been originally imple- 
mented as a set of extensions to Common Lisp. These 
extensions allowed both for generation of assembly code 
for a target hardware as well as a native execution, e.g., 
simulation [16]. Lisp, which was the language of choice 
among the artificial intelligence researches at that time, is 
particularly well suited to the implementation of a domain- 
specific solutions due to its extensibility features. Unfortu- 
nately, it does not leave any choice regarding the syntax 
convention. It is also difficult to distinguish between the 
domain-specific (architectural) and native Lisp constructs 
within a single notation. 

In [27], the authors present a solution to specify robot 
control modules and generate code skeletons. However, im- 
plementation of a complete toolset (i.e., parser for textual 
notation, generator templates and engine, syntax description 
files for common text editors) from scratch is time con- 
suming, thus this approach is not widely accepted. In [28] 
the EMF project tools are used to develop a modeling 
solution, including domain meta-model, graphical notation 
editor and generators for multiple artifacts (e.g., code and 
documentation). In [29], the authors use UML profiles to 
apply interaction patterns within a component-based robot 
control framework. 

These works, however, target horizontal domains, i.e., they 
do not raise abstraction level significantly nor present the 
problem in a more readable fashion. The real benefit and 
productivity improvement of domain-specific modeling is 
when applied to vertical domains, i.e., when an intuitive 
graphical notation and high-level concepts allows the devel- 
oper to focus on the design, not on the implementation. 

V. CONCLUSIONS 

In this paper we have presented a case study of a complete 
model-driven engineering process applied to the development 
of a domain-specific solution for an exemplary robot control 
architecture 1 . The model-driven engineering and DSMLs are 
relatively new concepts in the robotics research. For a long 
time the robotics community has been developing custom 
solutions that substitute the steps of a typical model-driven 
workflow. 

Most of the existing approaches to robot control can 
be summarized as providing patterns for dealing with the 
underlying complexity and describing control systems more 
concisely. DSMLs allows to capture these patterns, their 
relationships, meanings and symbols as a language vocab- 
ulary, grammar, semantics and notation, respectively [6]. 
Software language engineering provides methods and tools, 
which can be applied to the development of these languages. 
In particular, it enables the separation of concerns of the 
typical development workflow (e.g., concrete syntax, model 

'A complete source code, together with documentation of the presented 
modeling solution are available for download at http : //github . com/ 
ptro ja/ subsumption 



validation, code generation) and providing alternative im- 
plementations of the individual components (e.g., multiple 
notations and generators dedicated for specific platforms). 

DSMLs enables one to create new semantic levels that de- 
scribe certain abstractions more concisely. It is then possible 
to develop transformations (e.g., to check for validity) and 
generators (e.g., to translate into source code) for models cre- 
ated with these languages. In addition, semantics of DSMLs 
can be precisely specified with model-to-model transforma- 
tion by providing mapping into domain with already defined 
semantics (however, this has not been explored in this paper). 
Finally, all these tools can be combined and delivered as a 
single Integrated Development Environment (IDE). 

We believe, that model-driven engineering provides the 
necessary framework that enables the development of meth- 
ods and tools for robot control and programming in a much 
more disciplined and efficient manner than before. Dedicated 
tools for all the steps involved (i.e., definition of domain 
meta-model, multiple notations, model-to-model and model- 
to-text transformations) promise that the final solution can 
be delivered with much less effort. 
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